Computer Networks - Transport Layer

Computer Networks - Transport Layer#

Computer Networks - Transport Layer

The network layer only sends packets to the destination host, but the actual communication is between processes within the host. The transport layer provides logical communication between processes, masking the core details of the underlying network layer from higher-level users, making it appear as if there is an end-to-end logical communication channel between two transport layer entities.

Characteristics of UDP and TCP#

The User Datagram Protocol (UDP) is connectionless, delivers as much as possible without congestion control, is message-oriented (does not merge or split messages from the application, just adds a UDP header), and supports one-to-one, one-to-many, many-to-one, and many-to-many interactive communication.
The Transmission Control Protocol (TCP) is connection-oriented, provides reliable delivery, has flow control and congestion control, offers full-duplex communication, and is byte-stream oriented (treats messages from the application layer as a byte stream and organizes the byte stream into data blocks of varying sizes). Each TCP connection can only be point-to-point (one-to-one).

UDP Header Format#

The header fields consist of only 8 bytes, including source port, destination port, length, and checksum. A 12-byte pseudo-header is temporarily added for checksum calculation.

TCP Header Format#

Sequence Number: Used to number the byte stream. For example, if the sequence number is 301, it indicates that the first byte is numbered 301. If the length of the data carried is 100 bytes, then the sequence number of the next segment should be 401.
Acknowledgment Number: The sequence number of the next segment expected to be received. For example, if B correctly receives a segment sent by A with a sequence number of 501 and a data length of 200 bytes, then B expects the next segment's sequence number to be 701, and the acknowledgment number sent by B to A will be 701.
Data Offset: Refers to the offset of the data part from the start of the segment, which actually indicates the length of the header.
Acknowledgment (ACK): When ACK=1, the acknowledgment number field is valid; otherwise, it is invalid. TCP specifies that all transmitted segments must set ACK to 1 after the connection is established.
Synchronize (SYN): Used to synchronize sequence numbers during connection establishment. When SYN=1 and ACK=0, it indicates that this is a connection request segment. If the other party agrees to establish a connection, the response segment will have SYN=1 and ACK=1.
Finish (FIN): Used to release a connection. When FIN=1, it indicates that the sender of this segment has finished sending data and requests to release the connection.
Window: The window value serves as the basis for the receiver to allow the sender to set its sending window. This limitation is necessary because the receiver's data buffer space is limited.

TCP Three-Way Handshake#

Assuming A is the client and B is the server.

First, B is in the LISTEN state, waiting for the client's connection request.
A sends a connection request segment to B, with SYN=1 and ACK=0, choosing an initial sequence number x.
B receives the connection request segment and, if it agrees to establish a connection, sends a connection acknowledgment segment to A with SYN=1, ACK=1, acknowledgment number x+1, and also chooses an initial sequence number y.
After A receives B's connection acknowledgment segment, it sends an acknowledgment back to B, with acknowledgment number y+1 and sequence number x+1.
After B receives A's acknowledgment, the connection is established.

Reason for the Three-Way Handshake

The third handshake is to prevent invalid connection requests from reaching the server, which could cause the server to mistakenly open a connection.

If the connection request sent by the client is delayed in the network, it may take a long time to receive the connection acknowledgment sent back by the server. After waiting for a timeout retransmission time, the client will re-request the connection. However, this delayed connection request will eventually reach the server. If the three-way handshake is not performed, the server would open two connections. With the three-way handshake, the client will ignore any connection acknowledgment sent by the server for the delayed connection request and will not perform the third handshake, thus preventing the opening of another connection.

TCP Four-Way Handshake#

The following description does not discuss sequence numbers and acknowledgment numbers, as the rules for these are relatively simple. It also does not discuss ACK, as ACK is 1 after the connection is established.

A sends a connection release segment, with FIN=1.
B, upon receiving it, sends an acknowledgment. At this point, TCP is in a half-closed state, where B can send data to A, but A cannot send data to B.
When B no longer needs the connection, it sends a connection release segment, with FIN=1.
A, upon receiving it, sends an acknowledgment and enters the TIME-WAIT state, waiting for 2 MSL (Maximum Segment Lifetime) before releasing the connection.
After B receives A's acknowledgment, it releases the connection.

Reason for the Four-Way Handshake

After the client sends the FIN connection release segment, the server enters the CLOSE-WAIT state upon receiving this segment. This state allows the server to send any data that has not yet been transmitted. After the data is sent, the server will send a FIN connection release segment.

TIME_WAIT

After the client receives the FIN segment from the server, it enters this state. At this point, it does not directly enter the CLOSED state but must wait for a time set by a timer of 2MSL. This is done for two reasons:

To ensure that the last acknowledgment segment can arrive. If B does not receive the acknowledgment segment sent by A, it will resend the connection release request segment. A waits for a period to handle this situation.
To wait for a period so that all segments generated during the lifetime of this connection can disappear from the network, ensuring that a new connection will not encounter old connection request segments.

TCP Reliable Transmission#

TCP uses timeout retransmission to achieve reliable transmission: if a sent segment does not receive acknowledgment within the timeout period, it will retransmit that segment.

The time taken for a segment to be sent and then acknowledged is called Round-Trip Time (RTT). The weighted average RTT (RTTs) is calculated as follows:

where 0 ≤ a < 1, and RTTs becomes more sensitive to RTT as a increases.

The timeout period (RTO) should be slightly greater than RTTs. The timeout period used by TCP is calculated as follows:

where RTT_d is the weighted average of the deviation.

TCP Sliding Window#

The window is part of the buffer used to temporarily store the byte stream. Both the sender and receiver have a window, and the receiver informs the sender of its window size through the window field in the TCP segment. The sender then sets its window size based on this value and other information.

Bytes within the sending window are allowed to be sent, and bytes within the receiving window are allowed to be received. If the bytes on the left side of the sending window have been sent and acknowledged, the sending window will slide to the right by a certain distance until the leftmost byte is no longer in the sent and acknowledged state; the sliding of the receiving window is similar, where the leftmost bytes that have been sent, acknowledged, and delivered to the host will slide the receiving window to the right.

The receiving window will only acknowledge the last byte that arrives in order. For example, if the received bytes are {31, 34, 35}, where {31} arrives in order, but {34, 35} do not, it will only acknowledge byte 31. After the sender receives an acknowledgment for one byte, it knows that all bytes before that have been received.

TCP Flow Control#

Flow control is used to control the sending rate of the sender, ensuring that the receiver can keep up with the incoming data.

The window field in the acknowledgment segment sent by the receiver can be used to control the size of the sender's window, thereby affecting the sender's sending rate. Setting the window field to 0 means the sender cannot send data.

TCP Congestion Control#

If the network becomes congested, packets will be lost, and the sender will continue to retransmit, leading to even higher levels of network congestion. Therefore, when congestion occurs, the sending rate of the sender should be controlled. This is similar to flow control, but the motivations are different. Flow control is to ensure that the receiver can keep up, while congestion control aims to reduce the overall congestion level of the network.

TCP primarily uses four algorithms for congestion control: slow start, congestion avoidance, fast retransmit, and fast recovery.

The sender needs to maintain a state variable called the congestion window (cwnd). Note the difference between the congestion window and the sender's window: the congestion window is just a state variable, while the actual amount of data the sender can send is determined by the sender's window.

For discussion purposes, the following assumptions are made:

The receiver has a sufficiently large receive buffer, so flow control will not occur;
Although TCP's window is based on bytes, here the window size is measured in segments.

1. Slow Start and Congestion Avoidance#

Initially, the sender executes slow start, setting cwnd = 1, allowing the sender to send only 1 segment; upon receiving acknowledgment, cwnd is doubled, so the number of segments the sender can send thereafter will be: 2, 4, 8 ...

Note that in slow start, cwnd is doubled each round, which can cause cwnd to grow very quickly, increasing the likelihood of network congestion. A slow start threshold (ssthresh) is set, and when cwnd >= ssthresh, it enters congestion avoidance, where cwnd is increased by 1 each round.

If a timeout occurs, ssthresh is set to cwnd / 2, and slow start is executed again.

2. Fast Retransmit and Fast Recovery#

At the receiver, every time a segment is received, it should acknowledge the last received in-order segment. For example, if M₁ and M₂ have been received, and M₄ is received, it should send an acknowledgment for M₂.

At the sender, if three duplicate acknowledgments are received, it can be inferred that the next segment is lost, and fast retransmit is executed to immediately retransmit the next segment. For example, if three acknowledgments for M₂ are received, it indicates that M₃ is lost, and M₃ is retransmitted immediately.

In this case, only individual segments are lost, not due to network congestion. Therefore, fast recovery is executed, setting ssthresh = cwnd / 2 and cwnd = ssthresh, noting that it directly enters congestion avoidance.

The "slow" in slow start and "fast" in fast recovery refer to the setting values of cwnd, not the growth rate of cwnd. In slow start, cwnd is set to 1, while in fast recovery, cwnd is set to ssthresh.